FIG. 1 illustrates the system architecture for a conventional computer system, such as an IBM PS/2.RTM. personal computer ("PC"). The exemplary computer system of FIG. 1 is for descriptive purposes only. Though the description below may refer to terms commonly used in describing particular computer systems, such as an IBM PS/2.RTM. PC, the concepts equally apply to other systems, including those having dissimilar architectures.
The exemplary computer 100 includes a central processing unit ("CPU") 105, which may include a conventional microprocessor; a random access memory ("RAM") 110 for temporary storage of information; a read only memory ("ROM") 115 for permanent storage of information; a diskette controller 140 for controlling a diskette 142 that may be inserted into computer 100; a disk controller 150 for controlling a hard disk 152 that is local to the computer 100; a keyboard and mouse controller 155 for controlling a keyboard input device 156 and a mouse input device 157; a DMA controller 160 for performing direct memory access to RAM 110; a video controller 165 for controlling a video output display 170; a memory controller 120 for controlling RAM 110; a bus controller 125 for controlling bus 130; and an interrupt controller 135 for receiving and processing various interrupt signals. Communication controller 145 communicates via medium 147 to a network. Controller 145 may correspond to a local area network communication controller, for example, or a modem controller. Similarly, medium 147 may correspond to a tangible medium, such as local area network cable or a telephone link. Or, medium 147 may use wireless techniques, such as microwave or infrared transmission techniques.
The computer 100 is generally controlled and coordinated by operating system software, such as the OS/2.RTM. or DOS operating systems, developed and sold by the International Business Machines Corporation ("IBM"), Boca Raton, Fla. Conventional operating systems perform memory management, provide file system services, provide networking and I/O services, provide a user interface, such as a graphical user interface ("GUI"), and the like. User applications, such as editors and spread sheets, directly or indirectly, rely on these and other capabilities.
As is known in the art, operating systems often include most, if not all, of the above functionality; some provide more; some provide less. To better understand the system structure of two conventional operating systems, the following sections are provided.
1. Review of the DOS Operating System
FIG. 2 illustrates the DOS system structure 200. A user shell 201a, utilities 201b, application programs 201c, and terminate-and-stay-resident ("TSR") modules 201d generally form an outermost layer of the DOS operating system 200. The user shell 201a provides a user environment, including a prompt, and a command interpreter so that the computer may receive and process user commands. The outer layer of the operating system may directly use the inner layers, as well as the functionality of the other portions of the outer layer 201.
The next inner layer is the application-program interface ("API") layer 202, which provides an interface between the DOS kernel 203 and the outer layer 201. Consequently, the outer layers need understand only the level of abstraction defined by the API interface 202. Thus, application programs and the like may be developed without any regard as to the actual implementation of the kernel and other inner layers.
The next inner layer 203 is the DOS kernel. The DOS kernel provides known system supervisor functions.
The next inner layer 204 corresponds to the device drivers. Device drivers communicate with I/O devices and the like. As is known in the art, device drivers are highly hardware specific. The DOS operating system mandates a particular corresponding "device driver model." The device driver model defines a method of communication between the device driver and the DOS kernel. In some instances the device driver will communicate directly with the hardware. In other instances, device drivers may communicate with a ROM BIOS layer 205, which provides a layer of abstraction to the device driver. Among other things, the driver model defines the driver entry points that must be supported by a device driver to operate in the system and also defines the "calling conventions" for entering a driver.
As is known, DOS is a single-user, single-task system. Consequently, once a task gains control of the system, the task retains control until it has completed execution. Many system components, such as device drivers, rely upon this single-tasking paradigm of operation. For example, a DOS device driver may be constructed without functionality to handle contention issues. Under DOS, this is acceptable because the DOS operating system ensures that multiple processes will not run concurrently, and thus, multiple tasks cannot "contend" for a resource.
Those skilled in the art will appreciate that the above explanation is for descriptive purposes only and that the description of certain components has been simplified or omitted. Only those aspects that are material to understanding the invention are described. If a more detailed explanation is necessary, reference may be made to the numerous available materials that describe the DOS operating system in significant detail.
2. Review of the OS/2 operating system
The OS/2 operating system, unlike the DOS operating system, is a multi-tasking operating system. Under the OS/2 operating system, an application may request substantially more memory than under the DOS operating system. Moreover, multiple processes may concurrently execute and interact.
FIG. 3 illustrates the system structure 300 of the OS/2 operating system. As is readily seen, FIG. 3 is fairly similar construction to FIG. 2. A person skilled in the art, however, will appreciate that FIGS. 2 and 3 are at a high level of abstraction and that the implementations of the two systems are vastly dissimilar. For present purposes, this level of abstraction suffices, and the description of similar layers to those outlined above will not be repeated here, for the sake of brevity.
For purposes of understanding the invention, the principal difference between the DOS operating system and the OS/2 operating system is that the OS/2 operating system includes a layer 302a for dynamic link libraries "(DLLs)". DLLs are known and allow the binding of code and data in the DLL to be delayed, until the program or data of the DLL is actually loaded or until the program using the DLL specifically requests the operating system to dynamically link to the DLL.
3. Customer Investment and Compatability Issues
Over time, customers may make a substantial investment in a particular operating system. For example, customers may purchase various hardware devices, e.g., a magnetic tape reader, that are supported by device drivers of a particular operating system, such as DOS.
When a new operating system succeeds a prior operating system, often applications and other software are "ported" to the new operating system. "Porting" generally refers to the process of migrating the code to run under a new operating system. Sometimes this only involves recompiling source code; other times the code needs to be modified.
It is not uncommon for certain software--especially device drivers and other highly machine and/or operating system dependent software--to never be ported to a new operating system. This is so, because device drivers and the like are often written in lower level assembler code. As is known, low level code is more difficult to understand than higher level code. Consequently, software developers have difficulty deciphering the code, and this increases the porting cost. Further complicating the effort, device drivers and the like are usually constructed according to a device driver model that may be significantly different than that of the new operating system. Consequently, the porting effort will require developers who are proficient in both operating systems driver models, thus further encumbering the porting effort.
Other reasons may also affect the unavailability of a device driver and other software in a new operating system. For example, the company that originally provided the hardware and associated device driver may be out of business, or the company may have changed its product strategy to discontinue support for the device.
Consequently, users sometimes want to upgrade their computer system to use a new operating system, but are faced with the dilemma of losing a significant investment in their hardware and/or software. To this end, certain operating systems provide known compatibility functions to alleviate the loss.
For example, the OS/2 operating system allows the user to invoke a so-called "DOS session" through OS/2's multiple virtual DOS machine ("MVDM") facility. The MVDM feature is known and provides the user with a DOS environment, even though the OS/2 operating system is executing.
Theoretically, under MVDM, a DOS device driver may be installed into and used by a single DOS session. However, if two DOS sessions attempt to install and use the device driver, problems may likely result. This is so, not because of MVDM, but because the different sessions may contend for resources associated with the driver. As outlined above, the DOS driver was likely constructed for a single user, single tasking system in which such contention is not possible. Consequently, if two DOS sessions attempt to use the DOS driver contention may result, but the driver will have no mechanism to handle the contention. Data incoherency and other fatal errors, such as deadlock, may result.
Moreover, even if a user somehow ensures that a device driver will be installed and used by a single session only, the MVDM facility provides visibility to the device driver from a DOS emulated session. Consequently, though the user is able to use the driver, he or she is deprived of the full power of the OS/2 operating system because of the DOS emulation; for example, he or she is prevented from running large memory space multi-tasking, applications due to the DOS inherent constraints.
The description above made particular reference to DOS device drivers. The same concerns and problems are implicated for other DOS specific code, such as DOS network redirectors and terminate and stay resident modules ("TSRs") .
Consequently, it is an object of the present invention to provide a method and apparatus that allows users to use device drivers and other operating system specific code constructed for use in an operating system environment in an operating system environment of a different type.
It is another object of the present invention to provide compatibility to device drivers and the like of a first single-tasking operating system to applications running in a second multi-tasking operating system.